Traditionally, when two wireless devices seek to connect with each other, the first device has to obtain a device profile that contains the definitions of the second device before being able to connect to it. The second device's device profile provides all the necessary information for the first device to connect with it. The device profile is a set of definitions that are associated with that particular device and can include the GATT Profile and MAC address of that device. For example if the first device is a wireless router located in a home or office and the second device is a smartphone, in order for the wireless router to connect to the smartphone, the wireless router has to obtain a device profile from the smartphone.
The continued growth of the internet has seen not just the proliferation of a large number of smartphones, but has also brought about proliferation of a large number of various other connected devices. Although equipped with a wireless radio, these connected devices that have proliferated tend to be low-powered, low-energy devices as compared to a smartphone or a notebook computer. One category of these types of devices are Bluetooth low energy (BLE) devices. A more specific example of these various connected devices includes sensors such as those found in the Texas Instruments SensorTag®, which include an IR sensor, a humidity sensor, a gyroscope, an accelerometer, a magnetometer, a barometric pressure sensor, a temperature sensor, and a battery/voltage sensor. These connected devices also tend to have much less on-board memory as compared to a smartphone (megabytes of memory as compared to multiple gigabytes of memory). As such, a need has emerged for a system and method to reduce or eliminate the storage space required on a connected device to store its device profile.
Let us take the example of a corporation that sells home automation kits. These kits include a wireless router that functions as a gateway device, and a set of connected home automation devices such as a security alarm, a door lock, and a flood sensor. The traditional approach has been to store a pre-determined set of remote electronic device definitions and connecting information on the wireless router as software so as to allow the wireless router to connect to the devices within the pre-determined set. The definitions of the security alarm, the door lock, and the flood sensor are stored on the gateway as software because they are sold as a part of the home automation kit. Let us say this corporation has sold 100,000 such kits in the market to different consumers.
A common need for a consumer in this situation is the necessity to add new home automation devices at their homes as the products are designed and introduced, let us say a gas leak detector. However, adding this new device requires that the gateway be capable of connecting to and communicating with the new device, here a gas leak detector. Since the original pre-defined software of the set of devices did not include the gas leak detector, an update of the pre-defined set of software is needed. This means that the corporation has to send a software update to the gateways either remotely, or by physical means. Let us say that 500 customers are interested in adding the new gas leak detector. Further, at the same time, let us say that 1000 other customers want to add a different smoke detector. The current method of tackling this problem of diverse needs is that a larger than necessary update needs to be transferred from the corporation's server down to each customer's gateway because each gateway needs to support all the devices approved for use with the corporation's home automation service even though certain consumers are using only a subset of all the devices supported. As the number of supported devices increases and each succeeding update becomes larger, updates become a very daunting task for the corporation to keep up with.
One problem that has emerged with the proliferation of various connected devices is that simply there are a larger number of them when used in the applications they are designed for. The number of connected devices can be in the range of several hundreds to thousands of connected devices. Where in the traditional scenario a wireless router is connected to a smartphone in a one-to-one connection, there are now applications where a large number of low-powered sensors are connected to a single wireless router where the wireless router functions as a hub and the low-powered sensors are the ends of a spoke in a hub-and-spoke configuration. Because the large number of low-powered sensors are often slave devices and the wireless router controlling them is a master device, there is also a scenario where a second master device is switched in to take over control of the large number of low-powered sensors originally connected to the first master device. In this scenario, in order for the second master device to connect to the large number of low-powered sensors, each of the device profiles for the low-powered sensors must be fed to the new second master device. This consumes a significant amount of energy and can also needlessly take up precious computing resources on the side of the master device.
Another problem that occurs because of the way software is developed and implemented is the need for periodic (if not frequent) updates of devices. Frequent updates of software are not limited to the software running a piece of hardware (i.e., the smartphone's operating system or the low-powered sensor's firmware), but also applies to the individual pieces of software running on a device (e.g. a specific application running on the smartphone or the low-powered sensor). When a piece of software is updated by the software developer, the current method involves transferring the software from a server controlled by the software developer over the internet to the wireless router then to the device operating the software. This transfer is triggered by the developer's server informing the software on the device that there is a new version of the software or the software checking with the server whether there is a new version of the software and requesting that the software be transferred over.
However, despite the extraordinary level of connectivity between the software developer and their devices, there are still many instances where the server is not able to immediately contact the device to inform it that a new update is available. This problem can occur for a variety of reasons but one cause is that the device's owner may not keep a device constantly online. This problem is also caused by the design of low-powered sensors that enter into “sleep mode” so as to reduce power consumption. Also, low-powered sensors are not directly connected to the internet and hence a central server as they are connected via a wireless router and the wireless router may not always be connected to the internet. The result is that the software update may not reach the individual devices in a timely manner and at any time, devices or applications belonging to the same software developer may be operating different versions of a piece of software. Where software updates may contain a patch to a serious security flaw, this is a serious problem.
The invention being discussed solves this problem by not storing any device definition on the gateway. Instead, all device definitions are stored on a remote server that the gateway is connected to. When the gateway starts up, it downloads a list of device definitions that are relevant for the user that is using this gateway. The gateway then looks for the devices and connects to them. If the customer changes his list of devices, he/she updates a customer profile on the server and the gateway will now use the new set of definitions that are relevant. Every single customer could have a different set of devices, but the gateways will support each of them without the corporation having to send firmware updates.
An additional scenario is, if the definitions of existing devices changes, the erstwhile method will again need to issue firmware updates, whereas the new invention will be able to handle this with a single device definition update on the server that applies to all customers that use this device.
For the foregoing reasons, there is a need for a dynamic connectivity system where one wireless device does not need to obtain the device profiles of a large number of wireless devices before being able to connect to them.